In a distributed telecommunications network, communications among the “nodes” that comprise the network may use encryption protocols to secure communications among the nodes. As used herein, the term “node” refers to any device, apparatus, or mechanism that is part of a network.
Achieving secure communications in a distributed network requires a process for management and distribution of “encryption keys,” sometimes referred to as “keys,” to encrypt and decrypt communications. As used herein, the term “encryption key” refers to digital data that is used with an encryption algorithm to secure communications.
Two primary technologies may be used to secure the communications: public key (or asymmetric key) technology and symmetric (or shared key) technology. Public key technology uses public key—private key pairs, as described below. Shared keys are sometimes referred to as secret keys or private keys, with the latter not to be confused with the private keys of the public-private key pair in public key approaches.
Typically, these technologies for securing communications are associated with security infrastructure elements that are based on digital certificates that are generated based on exchanges of public keys (a “public key infrastructure” or “PKI”) or on exchanges of shared keys. PKI uses asymmetric or public key cryptography for identity management. The term “asymmetric” is used because of the application of two inverse keys comprising a public key and a private key. These keys are termed inverse because one key (e.g., the public key) is used to encrypt data while the other key (e.g., the private key) is used to decrypt the encrypted data. A public key is a key that is publicly known. A private key is known only to one party or a limited group of parties and is used to decrypt data that is encrypted with an associated public key. A shared key is shared between parties but is not generally known to the public. The parties that know the shared key use it to both encrypt and decrypt communications. Additional information on symmetric and asymmetric cryptography appears in B. Schneier, “Applied Cryptography” (New York: John Wiley and Sons, 2d ed. 1996).
In general, a trusted third party can provide a mechanism for exchanging keys. For example, in a Kerberos encryption system, a “key distribution center” or “KDC” may be used to exchange shared keys. The KDC is sometimes referred to as a key exchange authority or key exchange center. The KDC facilitates the exchange of shared keys by generating a shared key for two or more parties, and then sending the selected shared key to each party via encrypted messages to each party. The messages to each party may be encrypted with other shared keys known only to the KDC and each respective party. After the KDC distributes the new shared key to the parties, the parties can communicate without going through the KDC.
As another example, with PKI, a “certificate authority” or “CA” is typically employed. The CA establishes the identity of a particular node by binding the name of the particular node to a public key in a construct called a “certificate.” The certificate generally includes at least the following information: a version number, a serial number, the method used to sign the certificate (e.g., Rivest-Shamir-Adleman or RSA, or Digital Signature Algorithm or DSA), the name of the issuer of the certificate (e.g., the entity whose private key “signed” or encrypted the certificate), the valid time period during which the issuer will keep records for the certificate, the “subject name” that identifies the person, company, or node whose public key material is included in the certificate, and the subject's public key and public key method (e.g., RSA, DSA, or Diffie-Hellman).
Because there is only one private key associated with a public key, and the private key is used by a particular node, the CA can assure other entities that the public key is bound to the particular node. For example, the particular node can authenticate itself by proving knowledge of the private key that is associated with the public key, for example, by encrypting information that can be verified by the public key. The encrypted information is known as a digital signature, which can be created because the private key is only known to the particular node whose identify is bound in the certificate. Furthermore, a secured communication can be sent to the particular node by encrypting the contents of the communication using the public key from the particular node's certificate. Only the particular node of the associated private key may then decrypt the message.
Other nodes can trust that the certificate is valid because the CA digitally signs the certificate with the CA's private key to indicate authenticity. The signature of the CA can be verified by checking the digital signature against the public key certificate of the CA.
The CA, or an associated “registration authority” or “RA,” can issue and revoke certificates. Registration with the CA or RA is usually performed out of band (i.e., outside of the telecommunications network) by establishing the node's identity to the CA's satisfaction, such as by a telephone call or registration form that is provided (e.g., mailed, faxed, delivered, etc.) with required identification documentation. A “certificate revocation list” or “CRL” may be provided to enable a node to determine whether a certificate is still valid or has been revoked, such as by querying a revocation server that has the CRL.
Two nodes may establish secure communications using public key certificates that each node has registered. Typically, the public keys are used to establish a shared key that can be used to establish an encrypted communications channel, such as a virtual private network (VPN). For example, at the application level, the Secure Socket Layer (SSL) or Transport Layer Security (TLS) may be used. As another example, below the application level the Internet Protocol Security (IPsec) technology may be used. IPsec is typically implemented in two parts. The first part uses a two-phase approach based on the Internet Key Exchange (IKE) protocol, in which the first phase uses unencrypted exchanges to establish a set of shared keys to use in the second phase. The shared keys from the first phase are used in the second phase to establish encryption parameters for use in the second part for bulk encryption of the data to be exchanged. The first part is often referred to as the IKE security association (IKE SA) and the second part as the IPsec SA.
Communications over a telecommunications network may be classified based on how many nodes receive a communication as follows: unicast, multicast, and broadcast. With unicast communications, a single packet is sent from a source node to a destination node on a network. With multicast communications, a single data packet is copied by a source node and sent to a specific group of recipient nodes on the network. The source node addresses the packet with a multicast address, sends the packet to the network, and the network makes copies of the packet and sends a copy to each recipient node that is associated with the multicast address. Recipients of the multicast may act as a source node and send multiple copies of the packet to another group of nodes. With broadcast communications, the packet is addressed using a broadcast address so that the network will make and send a copy to every node on the network.
Regardless of the communication type, a particular communication may originate from another node besides the source node, such as from a user on a local area network (LAN) that is connected to the Internet via the source node. For example, in a multicast, the source node may be a router acting as a multicast originator and that connects the LAN to the Internet. Also, the recipient nodes may not be the ultimate destination of a communication, such as a communication to a user on a LAN that is connected to the Internet via a particular recipient node. For example, in a multicast, the recipient node may be a router acting as a multicast receiver and that connects a LAN to the Internet.
Secured communications can be achieved for unicast communications using the asymmetric and symmetric key approaches discussed above. For example, two nodes can establish secure communications using IPsec in which IKE is used by the nodes to negotiate the bulk encryption parameters for the unicast communication.
However, securing communications for multicast communications is more difficult than with unicast communications because in a multicast there are multiple destination, or recipient, nodes for each source, or origination, node. For example, while a pair of origination and destination nodes may negotiate back and forth in a unicast to achieve an agreed set of encryption parameters, negotiations rapidly increase in complexity with a multicast because the origination node must negotiate with a set of potentially many destination nodes. If all nodes are to use the same set of encryption parameters, the negotiations may be lengthy, as all nodes must agree on the encryption parameters. The negotiations over encryption parameters for a multicast may involve using key trees and graphs to arrive at a suitable encryption approach, which increases the complexity of establishing secured communications and consumes limited network resources. If different encryption parameters may be used by the origination node with particular groups of destination nodes, then the multicast only achieves the benefit of the more efficient multicast communication with those nodes using the same set of parameters, since the origination node must send a different multicast to each group of destination nodes.
Based on the foregoing, it is desirable to provide improved techniques for securing communications among multicast nodes.